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Abstract. This paper addresses issues regarding the application of artificial intelli- 
gence techniques to real-time control. Advantages associated with knowledge-based pro- 
gramming are discussed. A proposed rule-based control technique is summarized and 
applied to the problem of automated aircraft emergency procedure execution. Although 
emergency procedures are by definition predominately procedural, their numerous evalua- 
tion and decision points make a declarative representation of the knowledge they encode 
highly attractive, resulting in an organized and easily maintained software hierarchy. 
Simulation results demonstrate that real-time performance can be obtained using a 
microprocessor-based controller. It is concluded that a rule-based control system design 
approach may prove more useful than conventional methods under certain circumstances, and 
that declarative rules with embedded procedural code provide a sound basis for the con- 
struction of complex, yet economical, control systems. 
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INTRODUCTION 

The apparent success of knowledge-based systems, 
such as expert systems, to provide a limited human- 
like decision-making capability within a well- 
defined problem domain gives strong support to their 
use in the design and implementation of complex con- 
trol systems [1-4] . Before knowledge-based control 
techniques are ‘widely accepted, however, many ques- 
tions regarding their utility must be addressed. 
Why should a control system designer consider using 
knowledge-based programming techniques? What dis- 
tinguishes knowledge-based techniques from conven- 
tional ones, how should various know ledge -based con- 
trol ideas be evaluated and compared, which control 
problems call for a knowledge-based solution, and 
what specific benefits result from their use? 

This paper attempts to answer some of these ques- 
tions. The first section provides a comparison 
between conventional and knowledge-based program- 
ming, outlines some advantages associated with 
knowledge-based systems, and identifies some of the 
difficulties involved with applying these techniques 
to time-critical control. The second section summa- 
rizes an on-going research effort in real-time 
knowledge-based control designed to overcome these 
difficulties. The third section illustrates the 
utility of the proposed control technique by apply- 
ing it to the problem of automated aircraft emergen- 
cy procedure execution, and the final section summa- 
rizes benefits associated with its use. 


THE PROMISE OF KNOWLEDGE -BASED PROBLEM SOLVING 

One way knowledge-based systems can be distinguished 
from conventional software is by the manner in which 
data and the routines used to manipulate data remain 
separated within the program. As opposed to being 
written in a procedural manner whereby syntactic 
restrictions dictate an intermixing of code and 
data, know ledge -based systems use declarative state- 
ments, often in the form of rules, to declare and 
associate pieces of data. As the system runs, modi- 
fications and additions to the data are obtained 
through the use of an inference engine . In this 


case, the concept of data is generalized to mean 
knowledge, and the inference engine acts on the 
knowledge base (previously recognized as the data 
base) in hopes of inferring additional knowledge 
from that which already exists. The solution to a 
problem addressed by a knowledge-based system can 
come in the form of the additional knowledge (or 
information) inferred as a result of the system’s 
execution, as well as in the form of sequenced 
actions performed as side effects of its execution. 

The fundamental separation of a know ledge -based 
system into inference engine and knowledge base 
results in an enhanced capability for decision mak- 
ing and subsequent problem solving. The value of 
this enhancement, however, can mean different things 
to different people. While the user of a knovledge- 
based system may be impressed by the performance of 
the program itself, the designer of such a program 
also will appreciate the convenient environment pro- 
vided by the adoption of knowledge-based system 
techniques. For example, although creation of an 
effective and consistent knowledge base is the 
toughest part of system construction, the mechanical 
ease with which it can be prototyped, tested, and 
modified (given the proper software and hardware 
tools) reflects a significant increase in programmer 
productivity in comparison to similar programming 
efforts based on conventional methods [5,6]. The 
benefits of using know ledge -based techniques, there- 
fore, include not only what the resulting program 
can do, but also the efficient manner in which such 
a program may be created. It is within this context 
-- increased programmer productivity as well as pro - 
gram performance -- that the utility of knowledge- 
based techniques should be evaluated. 

Many factors complicate the use of knowledge- 
based systems technology in control. Time-critical 
and numeric in nature, conventional control algor- 
ithms exhibit computational characteristics radical- 
ly different from those exhibited by knowledge-based 
systems. The strength of knowledge-based systems 
comes from a symbolic processing capability, i.e. # 
the ability to reason with non-numeric data. Unfor- 
tunately, symbolic computation facilities, in addi- 
tion to being monetarily expensive, traditionally 
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result in slow execution speeds (in comparison to 
numeric facilities) and weak support for the repre- 
sentation and manipulation of floating-point numeric 
data types. Under the assumption that knowledge- 
based control efforts should build upon, and not 
attempt to replace, existing effective numerical 
control algorithms, a major challenge to control 
system designers is to integrate efficiently symbol- 
ic and numeric computation in a real-time environ- 
ment . 

Most control -oriented real-time knowledge-based 
systems developed to date can be characterized by 
(1) a separation within the control system of the 
symbolic and numeric processing environments (soft- 
ware and/or hardware), and (2) a supervisory role 
for the knowledge-based system, usually involving 
monitoring, diagnosis, and planning. Separation of 
the symbolic and numeric processing environments is 
justified by the fact that specialized software and 
hardware exist for this purpose. Moreover, as indi- 
cated in Fig. 1, sensing and control functions, con- 
ventionally based on numerical algorithms, usually 
are considered numeric processing tasks, whereas 
more general control system information processing 
usually is considered symbolic. Numeric processing 
historically has demonstrated the capability for 
high-bandwidth operation, whereas symbolic process- 
ing typically has been associated with low-bandwidth 
operation. Because sensing and control functions 
impose strict time constraints on control system 
design, separation of these high-bandwidth opera- 
tions from the conventionally lower-bandwidth infor- 
mation processing operations seems essential. 

Although justified, the separation of symbolic 
and numeric processing within a control system can 
limit severely the interaction between processing 
environments and the throughput of the system as a 
whole [7,8]. In time-critical applications such as 
fault-tolerant flight control, the throughput of a 
know ledge -based control system must be high. The 
present research goal is to integrate the desirable 
attributes of procedural and declarative techniques 
for efficient and effective control system program- 
ming, combining convenience in design with speed, 
economy, and high symbolic/numeric integration in 
implement at ion . 



TASK FUNCTION 

(a) 



Fig. 1. Characteristic Relationship between Task Function, 
Processing, and Bandwidth 


Princeton Rule-Based Controller (PRBC) [9-11] 
embodies a control technique whereby control actions 
occur as a consequence of search through a knowledge 
base of parameters , rules , and procedures . Parame- 
ters, each with an assigned value, collectively rep- 
resent a partial description of the "state of the 
world" pertinent to a given control objective. 
Search implies the attempt to increase the system's 
knowledge of the world by inferring additional 
parameter values, most of which are assumed unknown 
when the search begins. Information expressing 
relationships and dependencies between parameters is 
contained in rules, each of which contains a premise 
and an action . If a rule premise is true when test- 
ed, its action is executed, possibly causing the 
inference of additional parameter values. Rule 
testing is guided by an inference engine. 

Control actions occur as side effects of search. 
Buried within the premises and actions of rules are 
procedures (or calls to procedures) that invoke 
time-critical control tasks that are best achieved 
using proven analytical techniques. These proce- 
dures are treated as building blocks upon which 
higher-level control actions are built using rules. 
Thus, in its simplest form, rule-based search con- 
veniently implements deeply nested IF-THEN-ELSE 
clauses. The resultant ability to perform complex 
conditional branching in an organized manner pro- 
vides a convenient mechanism with which to manipu- 
late analytically derived numerical procedures. In 
this scenario, it is not the end result of a search 
that is important to control system operation but 
the side effects of its execution. 

Such use of rules for control results in a tight 
functional integration between symbolic rules and 
numerical procedures. In this sense, the technique 
addresses the desired movement of the curve repre- 
sented in Fig. la by admitting symbolic processing 
at the sensing and control level. Figure lb, how- 
ever, implies a concurrent desire to increase the 
bandwidth of symbolic processing, thereby addressing 
the issue of system throughput. The approach adopt- 
ed here involves two distinct design phases. Phase 
I involves the development of rules and procedures 
in separate environments. LISP is used to create 
and test rules, whereas Pascal is used to derive 
procedures. Phase II involves final rule and proce- 
dure debugging in an integrated Pascal implementa- 
tion environment. Phase I utilizes a LISP-based 
inference engine, whereas Phase II uses one based in 
Pascal. The transition from Phase I to Phase II 
involves the automatic translation of the LISP-based 
parameters, rules, and parameter-rule association 
information into a form acceptable to the Pascal- 
based inference engine. This knowledge base trans - 
lat ion represents a form of automatic code optimiza- 
tion, and results in a compile-ready program 
implementing a search environment functionally simi- 
lar to that based in LISP, but exhibiting the proven 
real-time control system performance characteristics 
of Pascal [ 12] . 

The advantages associated with an integrated Pas- 
cal implementation environment are many. In addi- 
tion to increasing search speed dramatically, knowl- 
edge base translation allows rules and procedures to 
communicate through common data structures. Because 
parameters are implemented as Pascal variables, 
their values can be inspected and modified easily by 
procedures. Similarly, rules are free to access 
variables other than knowledge base parameters, such 
as the elements of a matrix routinely used by a 
numerical procedure. Finally, additional integra- 
tion results from the ability to place arbitrary 
Pascal statements within the premises and actions of 
rules. The search process can thereby invoke timely 
pieces of Pascal code (calling a procedure, for 
example) as easily as Pascal code can invoke the 
process of search. 
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Although the search technique utilized here for 
control was inspired by that used in rule-based 
expert systems, it differs significantly in both 
implementation and intent. The use of rules in 
expert systems often is influenced by the character- 
istics of pure production systems. In production 
systems, each rule is considered a distinct and mod- 
ular piece of knowledge, with explicit dependence of 
one rule on another being discouraged. Rules are 
meant to communicate with other rules through the 
indirect and limited link provided by the parameters 
of the knowledge base, but the intentional calling 
of one rule by another using parameter values as 
messages is looked upon with disfavor. As Davis and 
King [2] point out, "It is the premeditated nature 
of such message passing (typically in an attempt to 
'produce a system with a specified behavior') that 
is the primary violation of the 'spirit' of produc- 
tion system methodology." 

Given that the goal of a control system is, in 
fact, to produce a system with a specified behavior, 
it is not surprising that some control system 
designers view the application of pure production 
system techniques to control to be misguided. It is 
the intent of the rule-based control concept dis- 
cussed here, however, not to take a pure production 
system approach, but to utilize the declarative pow- 
er of the production system formalism for its bene- 
ficial effects. This effort may be summarized, 
therefore, as the attainment of procedural activity 
through the manipulation of declarative expressions, 
which is not an entirely new idea [13]. The unique- 
ness in this effort comes from its application to 
the design and implementation of time-critical con- 
trol systems, particularly flight control systems. 
Although violating the spirit of pure production 
systems in order to provide the specified behavior 
demanded for control, the proposed control technique 
retains many advantages related to production sys- 
tems. Davis and King [2] provide an interesting 
perspective related to program performance and pro- 
grammer productivity as mentioned above. 

Since it is possible to imagine coding 
any given Turing machine in either pro- 
cedural or production system terms, in 
the formal sense their computational 
power is equivalent. This suggests 
that, given sufficient effort, they are 
ultimately capable of solving the same 
problems. The issues we wish to examine 
are not, however, questions of absolute 
computational power but the impact of a 
particular methodology on program struc- 
ture, as well as of the relative ease or 
difficulty with which certain capabili- 
ties can be achieved. 

The next section illustrates the straightforward 
manner in which significant control system capabili- 
ties may be obtained using rules. 

DECLARATIVE EXECUTION OF AIRCRAFT EMERGENCY 
PROCEDURES 

The rule-based control technique described above was 
developed as part of a research program in applica- 
tions of artificial intelligence theory to fault- 
tolerant flight control [14]. Presently, the tech- 
nique is being applied to the automation of aircraft 
emergency procedures. Aircraft emergencies require 
a quick response and relatively complex decision 
making by a flight crew. Prescribed emergency pro- 
cedures contained in the Pilot's Operating Handbook 
are designed to guide the flight crew through the 
decision-making process. Although these emergency 
procedures are by definition predominately procedur- 
al, their numerous evaluation and decision points 


make a declarative representation of the knowledge 
they encode highly attractive. 

Consider as a simple example the following 
excerpt of an emergency procedure associated with 
the electrical system of the CH-47C tandem-rotor 
helicopter [ 15 ] : 

4-96. FAILURE OF ONE AC GENERATOR. 

4-97. Should one ac generator fail, the 
remaining ac generator will assume the 
entire load under normal conditions. 

This condition will be noticed by the 
illumination of a generator caution 
light and by a zero indication on the ac 
loadmeter for that generator. Attempt 
to place the inoperative ac generator 
into operation by performing the follow- 
ing: 

a. Master caution lights - PUSH TO 
RESET. 

b. All circuit breakers - CHECK. 

c. Generator switch - TEST, then 
RESET, then ON. If the generator is 
inoperative, move the generator switch 
to OFF. (Move the generator switch to 
TEST and observe the generator caution 
light. If the caution light goes out, 
the generator is delivering proper volt- 
age and frequency and a short circuit on 
a bus is indicated. If the caution 
light remains on, the generator is inop- 
erative . ) 

The following discussion highlights how this 
emergency procedure (with reference to Generator 
No.l only) can be made to execute automatically as a 
side effect of search through a knowledge base of 
parameters and rules. The inference engine executes 
on the highest level a repetitive cycle involving 
knowledge base initialization and goal-directed 
search on a parameter named PROC_SEARCH_COMPLETED. 
This is represented in Pascal as 
repeat 

initialize_knowledge_base ; 
det e rmine_va 1 ue_of ( PROC_SEARCH_COMPLETED) 
until false; 

Knowledge base initialization assigns the value of 
UNKNOWN to all parameters without a stored "initial 
value". Goal -directed (backward-chaining) search on 
parameter PROC_SEARCH_COMPLETED results in the 
inference engine testing rules capable of supplying 
a value for this parameter in their action, such as 
the following. 

[R0LE_PR0C_1 

[PREMISE 

' ( $0R (SEQ PROC REQUIRED ’FALSE) 

($EQ PROC_STEP_CHECKED ’TRUE] 

[ACTION 

'(5SETQ PROC_SEARCH_COMPLETED 'TRUE]] 

Note that the premise of this rule depends on other 
parameters whose values also are as yet unknown 
(parameters receiving a value of UNKNOWN during 
knowledge base initialization are written entirely 
in capital letters). When tested, the premise first 
searches for a value for parameter PROC_REQUIRED. A 
value of FALSE implies that the emergency procedure 
is not required (the conditions under which it is to 
be executed do not exist). The following rules 
determine whether or not procedure requirements are 
met . 
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(RULE_PROC_REQ 1 

(PREMISE 

1 ($AND ($EQ Proc_Step 0) 

($EQ Gen_l_Control_Switch_Status ’ON) 
($EQ Gen_l_Loadmeter_Status 0) 

($EQ Gen_l_Caution_Light_Status ’ON) 

(SEQ Gen_2_Caut ion - Light_Status 'OFF] 

(ACTION 

' ( (SSETQ ProcStep 1) 

($SETQ PROC_REQUIRED ’TRUE]] 

( RULE_PR0C_REQ_2 
[PREMISE 

'(SGT Proc_Step 0) 

(ACTION 

'(SSETQ PROCURE QU I RED ’TRUE]] 

( RULE_PR0C_REQ_3 
(PREMISE 

’ ($EQ Rule_Tested ’TRUE] 

(ACTION 

’(SSETQ PROC_REQUIRED ’FALSE]] 

Rules are tested in order of appearance in the 
knowledge base until a value for the specified 
parameter is obtained. These three rules are tested 
in order when a value for PROC_REQUIRED is needed 
within the premise of RULE_PROC_l. The premise of 
the first rule holds if the procedure is not already 
executing (the active procedure step number, repre- 
sented by parameter ProcStep, is 0) and the condi- 
tions specified by the remainder of the SAND clause 
prevail. The second rule holds if the procedure is 
already executing (Proc_Step is greater than 0), and 
the third rule always holds whenever tested. Thus, 
if during search only the third rule holds, then 
PROCREQUIRED obtains a value of FALSE, and 

PROC_SEARCH_COMPLETED is assigned a value of TRUE 
within the action of RULE_PR0C_1 quickly ending the 
search cycle. However, if RULE_PR0C_REQ_1 holds, 
then the step number is set to 1, PR0C_REQUIRED 
obtains a value of TRUE, the first subclause of 
RULE_PR0C 1 fails, and a goal-directed search for 
PR 0C_STEP~ CHECKED begins. A similar search will 
prevail if RULE_PR0C_REQ_1 fails, but 
RULE_PR0C_REQ_2 holds. 

Emergency procedures are executed here as a 
series of steps. Steps are executed one at a time, 
in order. Each step in general involves an initial 
action (invoked for Step 1 by parameter 
PR0C_STEP_1_STARTED) , a time delay (reflected by 
parameter Proc_Step_Delay) over which the initial 
action is allowed to take effect, and a final action 
(invoked for Step 1 by parameter 
PR0C_STEP_1_FINISHED) . For example, an emergency 
procedure may require the flipping of a switch and 
the monitoring of its effect. The time delay 
between the initial and final step actions gives the 
physical system being probed a chance to react. 
When a final step action is taken, Proc_Step is 
incremented, allowing the next emergency procedure 
step to be performed. 

Rules invoked by cyclic goal-directed search 
effectively encode the logic required to execute 
these emergency procedure steps with the appropriate 
time delays. As shown by the rules above, cyclic 
search on parameter PR0C_SEARCH_C0MPLETED results in 
cyclic search on parameter PROC_STEP_CHECKED (assum- 
ing that PR0C_REQUIRED is TRUE). In effect, ^the 
control system continually asks the question, "Has 
the appropriate emergency procedure step been 
checked?" Rules capable of answering this question 
for Step 1 are shown below. 

[ RULE_PR0C STEP_1A 
[PREMISE” 

’ ($AND ($EQ ProcStep 1) 

(SEQ Proc_Step_Timer ’STOPPED) 

($EQ PR0C_STEP_TIMER_SET ’TRUE) 

($EQ PR0C_STEP_1_STARTED ’TRUE]] 

[ACTION 

’(SSETQ PR0C_STEP_CHECKED ’TRUE]] 


[RULE_PR0C_STEP_1B 

[PREMISE 

’(SAND 

(SEQ Proc_Step 1) 

(SEQ Proc Step Timer ’RUNNING) 

($0R [SAND 

(SEQ PR0C_STEP_1_BYPASSED ’TRUE) 
(SEQ PROC STEP_TIMER_SET ’TRUE] 
(SEQ PR0C_STE P_T I ME OUT ’FALSE]] 

[ACTION 

’(SSETQ PR0C_STEP_CHECKED ’TRUE]] 

[RULE_PR0C_STEP_1C" 

[PREMISE 

'(SAND (SEQ Proc Step 1) 

(SEQ Proc^StepJTimer ’RUNNING) 

(SEQ PR0C_STEP_TIME0UT ’TRUE) 

(SEQ PR0C_STEP_1 FINISHED ’TRUE) 

($EQ PR0C_STEPjriM£R_SET ’TRUE]] 

[ACTION 

’(SSETQ PR0C_STEP_CHECKED ’TRUE]) 

When a value for PR0C_STEP_CHECKED is required by 
Rl’LE_PROC_l , these rules are tested. Each rule per- 
forms a distinct intra-step function, monitoring the 
"state" of Procedure Step 1 and quickly performing a 
piece of the step if required. At least one rule 
always holds. Within the first rule, the parameter 
Proc_Step_Timer is checked for a value of STOPPED. 
This indicates that the step has not begun. In which 
case the timer is started (via search for parameter 
PR0C_STEP_TIMER_SET using rules not shown) and the 
initial step action is taken (via search for parame- 
ter PR0C_STEP_1_STARTED) . If the first rule fails 
(Proc_Step_Timer is RUNNING), a search for parameter 
PR0C_STEP_1_BYPASSED within the second rule checks 
whether or not the final step action already has 
been performed by the flight crew. If it has, 
PR0C_STEP_1_BYPASSED will return a value of TRUE and 
a search on PR0C_STEP_TIM£R_SET will stop the timer 
and increment Proc_Step. If PR0C_STEP_1_BYPASSED is 
FALSE, the next premise subclause tests whether or 
not the required step time delay has been achieved. 
If PR0C_STEP_TIME0UT is FALSE (inferred with a rule 
not shown), the rule premise holds without perform- 
ing any emergency procedure actions. If 

PR0C_STEP_TIME0UT is TRUE, the third rule performs 
the final step action (via search for parameter 
PR0C_STEP_1_FINISHED) and stops the timer and incre- 
ments Proc_Step (via search for parameter 
PR0C_STEP_TIMER_SET) . 

Thus, each search for parameter PROC_STEP_CHECKED 
performs a single piece of a single procedure step. 
Execution of the entire emergency procedure requires 
many search cycles. The following three Step 1 
rules encode the first part of the emergency proce- 
dure excerpt shown above. 

[ RULE_PR0C_STEP_ 1_ST 
[PREMISE 

'($AND (SEQ Advisory_Mode *0N) 

(SPASCAL "advise 

(’*** EMERGENCY PROCEDURE *** 
Failure of One AC Generator: 
a. Master caution light - 
PUSH TO RESET’);’’) 

(SSETQ ProcStepDelay 1.0] 

[ACTION 

’(SSETQ PR0C_STEP_ 1_STARTED ’TRUE]] 

[RULE PR0C_STEP_ 1_BY 
[PREMISE 

'(SEQ Master_Caution_Light_Status ’OFF) 
[ACTION 

'(SSETQ PR0C_STEP_1_BYPASSED ’TRUE]] 

[RULE_PR0C_STEP_1_FIN 
[PREMISE 
’ (SAND 

($EQ Operational Jlode ’ACTIVE) 

(SSETQ Master_Caution_Light_Command ’PUSH) 
[ACTION 

'(SSETQ PR0C_STEP_1_FINISHED ’TRUE]] 
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The premise of the first rule contains three sub- 
ciauses. The first subclause holds if parameter 
Advisory_Mode has value ON. If so, the next two 
subclauses are evaluated. The $PASCAL subclause 
contains embedded Pascal code that calls a procedure 
which sends an advisory message to the cockpit for 
evaluation by the flight crew. The SSETQ subclause 
assigns to parameter Proc_Step_Delay a value of 1. 
Both of these subclause operators, as members of a 
Boolean premise, always return TRUE. Similarly, the 
premise of the third rule generates a master caution 
light command within the $SETQ subclause if parame- 
ter Operat ional_Mode has value ACTIVE. Thus, for 
Procedure Step 1, if Advisory_Mode is ON and Opera- 
tional_Mode is ACTIVE, the control system will reset 
the master caution light if after 1 sec this task 
has not been performed by the flight crew. In gen- 
eral, the parameter Advisory_Mode can have values ON 
and OFF, and parameter Operat ional_Mode can have 
values ACTIVE and STANDBY. If Advisory_Mode is OFF, 
no recommendations are sent to the flight crew, and 
advisory delays are eliminated. If Operational_Mode 
is STANDBY, actions may be recommended but not exe- 
cuted by the flight control system. 

If any of these three rules fails, an additional 
rule supplying an appropriate "default" value for 
the required parameter is tested, such as the fol- 
lowing. 

[RULE PROC STEP_1 BY 0 
[PREMISE 

' ($EQ Rule_Tested ’TRUE] 

[ACTION 

' (SSETQ, PR0C_STEP_1_BYPASSED ’FALSE] ] 

The remaining parts of the emergency procedure 
excerpt given above are implemented in a similar 
fashion. Consider the next three rules. 

[ RULE_PR0C_STEP_2_ST 
[PREMISE 

'(SAND 

($EQ Advisory_Mode ’ON) 

(SPASCAL "advise 

('b. All circuit breakers - CHECK');’’) 
(SSETQ Proc_Step_Delay 2.0] 

[ACTION 

’(SSETQ PR0C_STEP_2_STARTED ’TRUE]] 

[RULE PR0C_STEP 2_BY 
[PREMISE 

* ($EQ BREAKERS_CHECKED_BY_FLI GHTCREV ’TRUE] 
[ACTION 

’(SSETQ PR0C_STEP_2_BYPASSED ’TRUE]] 

[RULE_PR0C_STEP_2_FIN 

[PREMISE 

'(SAND (SEQ OPERATI 0NAL_M0DE ’ACTIVE) 

(SEQ BREAKERS_CHECKED_BY_FCS ’TRUE] 

[ACTION 

’(SSETQ PR0C_STEP_2_FINISHED ’TRUE]] 

The first rule provides an advisory with a 2 sec 
grace period. Within this time period, a goal- 
directed search on parameter 

B RE AKERS_CHECKED_BY_F LI GHTCREV performed within the 
second rule invokes additional rules that check if 
all circuit breakers have been checked by the flight 
crew. The third rule invokes other rules performing 
this task automatically if and when necessary. 

The last part of the emergency procedure is 
implemented with two steps. Rules of Procedure Step 
3 verify movement of the generator switch to the 
TEST position. If Advisory_Mode is OFF, the control 
system performs the action immediately. If Adviso- 
ry_Mode is ON, a maximum advisory delay of 1 sec is 
tolerated. Finally, rules of Procedure Step 4 wait 
one more second (regardless of Advisory_Mode) before 
moving the generator switch to ON or OFF, depending 
on the status of the generator caution light. 


The result of using a declarative rule-based rep- 
resentation for emergency procedure execution is an 
organized and easily maintained software hierarchy. 
Additionally, by using cyclic search with "time- 
sliced" procedure steps, the action of the control 
system can be made to emulate a multi-tasking oper- 
ating system. This capability is demonstrated 
below. 

Figure 2 shows a time history of the amount of 
"effort" expended by a single-processor rule-based 
controller executing the emergency procedure 
described above. The data was obtained with the 
Princeton Rule-Based Controller Development System 
[9], employing a commercial lv-available single-board 
computer outfitted with an 8-MHz 80286 processor and 
an 8-MHz 80287 math coprocessor. The controller 
knowledge base contained 34 parameters and 34 rules. 
Off-line LISP-to-Pascal knowledge base translation 
required 8.6 min on a personal computer functionally 
similar to the PRBC processor described above. Pas- 
cal representation of the knowledge base required 16 
KBytes of Random-Access Memory (some as code, some 
as data), and the inference engine required 13 
KBytes of code. 

During simulation runs, certain parameters were 
given a fixed initial value: Gen__l_Loadmeter_Status 
was 0, Gen_2_Caut ion_Light_Status was OFF, 
BREAKERS_CHECKED_BY_FLI GHTCREV was FALSE , 
BREAKERS~CHECKED_BY_FCS was TRUE. Emergency proce- 
dure execution was triggered by changing the value 
of Gen_l_Caution_Light_Status from OFF to ON. Each 
data point in the top plots of Fig. 2 corresponds to 
the number of rules tested by the inference engine 
during a goal-directed search cycle. Adjacent data 
points are separated by the amount of time required 
to complete a search cycle. Figure 2 shows that 
although the value of the parameter Advisory_Mode 
has a large effect on emergency procedure step tim- 
ing (as intended), the inference engine consistently 
executes search cycles at a very high rate. 
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Figure 3 shows a time history of rule testings 
performed by the same rule-based controller concur- 
rently executing five copies of the same emergency 
procedure. Although all procedures trigger off the 
same generator caution light, each manipulates its 
own master caution light and generator switch, and 
employs a unique set of step delays. Figure 3 shows 
that this version of the rule-based controller, with 
a knowledge base of 154 parameters and 170 rules, 
still provides real-time multi-tasking performance 
with a single economical processor. 

CONCLUSIONS 

The main conclusion to be drawn is that a rule-based 
control design approach may prove more useful than 
conventional methods under certain circumstances, 
especially when complex decision making is required. 
The proposed rule-based control technique provides 
basic programming constructs required in real-time 
applications such as flight control. Capabilities 
including event scheduling, selection, and synchron- 
ization, as well as data passing and sharing, are 
implemented in an extremely flexible and modular 
representation. Consequently, declarative rules 
with embedded procedural code provide a sound basis 
for the construction of complex, yet economical, 
control systems. 


Advisory_Mode ON 



Time (sec) 


GLS - Gen_ 1 _Caution_Light_Status 

MLSn - Master_Caution_Light_Status for Procedure n 

GSSn - Gen_1_Control_Sw(tch_Status for Procedure n 


Fifl. 3. Execution of Multiple Concurrent Emergency Procedures 
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